[% setvar title The Perl 6 Summary for the fortnight ending 20031123 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the fortnight ending 20031123'></a><h1>The Perl 6 Summary for the fortnight ending 20031123</h1>
<p>Right, hopefully things are back to normal(ish) after the disk crashes
that rather spoilt the last summary. I've managed to fill in my mail
archive too so this summary will cover the events of the last
fortnight (that's two weeks for those whose version of English lacks
this vital unit of time).</p>
<p>We start, as usual, with all the action in perl6-internals.</p>
<a name='Unifying call and return'></a><h2>Unifying call and return</h2>
<p>It's been a long time coming, but Dan returned from LL3 suitably
refreshed by his dealings with academics (&quot;You can [...] consider a a
sub PMC as a frozen semi-stateless continuation&quot;) and set about
unifying Parrot's call and return conventions. The strange thing is
that everyone's been wanting this for months now, but that didn't mean
there wasn't discussion.</p>
<p>Meanwhile Melvin Smith set about making this discussion moot (from the
point of view of someone targeting Parrot) by hiding the details
behind IMCC directives (which already happens admittedly, but
Melvin's in the process of renaming the <code>.pcc_*</code> directives to get
rid of the <code>.pcc_</code> and (eventually) allowing for pluggable calling
conventions.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.58.0311100905190.15737@sprite.sidhe.org' target='_blank'>groups.google.com</a> -- Dan's heads up</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.58.0311121141090.28619@sprite.sidhe.org' target='_blank'>groups.google.com</a> -- Changes, draft 1</p>
<p><a href='http://groups.google.com/groups?selm=a06010201bbdd728d2b16@' target='_blank'>groups.google.com</a>[10.0.1.2] -- Dan puts his foot down</p>
<p><a href='http://groups.google.com/groups?selm=5.1.1.6.2.20031115234124.020a7f60@pop.mindspring.com' target='_blank'>groups.google.com</a> -- Melvin Makes it Moot</p>
<a name='Reviewing a book about VMs'></a><h2>Reviewing a book about VMs</h2>
<p>St&eacute;phane Payrard bought a copy of &quot;Virtual Machine Design and
Implementation in C++&quot; and reviewed it for perl6-internals. He didn't
like it. Which is putting it mildly.</p>
<p>This led to the inevitable questions about finding good books on VM
design. St&eacute;phane quoted Leon Brocard's preemption of this
question from London.pm: &quot;No, there's surprisingly little out there on
virtual machine design and development&quot;.</p>
<p><a href='http://groups.google.com/groups?selm=20031113173044.GB5924@stefp.dyndns.org' target='_blank'>groups.google.com</a></p>
<a name='IMCC gets high level sub call syntax'></a><h2>IMCC gets high level sub call syntax</h2>
<p>Melvin Smith continues to make PIR less like Assembly language and
more like pseudo code. You can now write code like:</p>
<pre>   _foo()
   var = _foo()
   var = _foo(a, b)
   (var1, var2) = _foo(a, b)</pre>
<p>and IMCC will do the Right Thing. Go Melvin.</p>
<p><a href='http://groups.google.com/groups?selm=5.1.1.6.2.20031116195005.03c2c488@pop.mindspring.com' target='_blank'>groups.google.com</a></p>
<a name='IMCC problems with library loading'></a><h2>IMCC problems with library loading</h2>
<p>Jeff Clites pointed out some issues with IMCC's behaviour when loading
external libraries and wondered about definitive docs on the macro
syntax (I think the current definitive docs may well be the source
code). Leo T&ouml;tsch seemed to accept that there were issues with
the current state of IMCC in this context, but implied that fixing it
wasn't an immediate priority.</p>
<p><a href='http://groups.google.com/groups?selm=C5EC6699-18A1-11D8-92BE-000393A6B9DA@mac.com' target='_blank'>groups.google.com</a></p>
<a name='A new list proposal'></a><h2>A new list proposal</h2>
<p>Melvin Smith proposed creating a parrot-compilers mailing list as
a general purpose list for any and all language development targeting
Parrot. He even went so far as to volunteer to maintain and distribute
the FAQ.</p>
<p>The immediate response was positive, but Leo and others didn't really
think the volume of traffic currently warranted it (which, I think,
was part of Melvin's point, Parrot is reaching the point where it can
just be <i>used</i> without necessarily needing to worry over much about
its internals. I think Melvin is concerned that the technical level
(and implicit Perlcentricity) of the current internals list is putting
potential compiler developers off participating).</p>
<p>So, if you're reading this because you're interested in using Parrot
as a target platform, but you don't subscribe to the internals list
but would subscribe to a parrot-compilers list, could you let me,
Melvin, or the list know? I've already committed to including any such
list in my summaries (at least until traffic reaches the point where
someone decides to do a dedicated summary). Let us know if you think
it's a terrible idea too of course.</p>
<p><a href='http://groups.google.com/groups?selm=5.1.1.6.2.20031117135818.021515f8@pop.mindspring.com' target='_blank'>groups.google.com</a></p>
<a name='Parrot Documentation Review'></a><h2>Parrot Documentation Review</h2>
<p>Michael Scott posted a review of Parrot documentation with pointers of
where to find existing docs and a discussion of where people <i>should</i>
be looking. Somewhat bizarrely, he failed to give the URL of the
Parrot Wiki, his favoured source of documentation (favoured for the
very good reason that it's excellent). However, you'll find the URL below.</p>
<p><a href='http://groups.google.com/groups?selm=47906C10-1959-11D8-AC7B-0050E479991D@mac.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://www.vendian.org/parrot/wiki/' target='_blank'>www.vendian.org</a> -- The very lovely and worthwhile parrot Wiki</p>
<a name='Freeze is in'></a><h2>Freeze is in</h2>
<p>Dan announced that he's checked in Leo's preliminary patch
implementing freeze/thaw, commenting that it's likely to change
dramatically internally and that the vtable/low-level API wasn't
final, but that the op-level interface would be stable. Jeff Clites
was initially concerned that the patch used things he was expecting to
be able to use for his (in progress) ordered destruction
patch. However, after some discussion, he and Leo seem to be confident
that the two things can be unified.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.58.0311191201490.7503@sprite.sidhe.org' target='_blank'>groups.google.com</a></p>
<a name='Warning Patrol'></a><h2>Warning Patrol</h2>
<p>J&uuml;rgen B&ouml;mmels has been doing a little warning patrol of
parrot and finds that only a very few fixes to IMCC are required to
get a warning-free compile and posted a patch with them in. Leo
applied it immediately, reasoning that, whilst IMCC's under heavy
development, there's no excuse for throwing compile warnings, and
every time the perpetrators have to integrate such patches they'll
become more likely to try not to generate the warnings in the first
place.</p>
<p>Inspired by this, Jonathan Worthington posted a similar patch to
eliminate warnings when building for win32, which Leo also applied.</p>
<p><a href='http://groups.google.com/groups?selm=m24qwzgj0y.fsf@helium.physik.uni-kl.de' target='_blank'>groups.google.com</a></p>
<a name='Finished/stable parts of Parrot?'></a><h2>Finished/stable parts of Parrot?</h2>
<p>Robin Redeker wondered which bits of Parrot and IMCC could be
considered stable enough to use in implementing a language. Leo opined
that existing syntax will not change much, most of the expected
changes relate to things like adding support for calling conventions
and simplifications like replacing <code>.pcc_sub</code> with <code>.sub</code>. Melvin
Smith pitched in with rather more detail about what was expected to
change and the kind of changes that could be expected in the
future. Reading this it's apparent that we've reached the point where
almost any conceivable extension to IMCC will be backward compatible
with earlier versions. Famous last words I know, but it is looking
that way.</p>
<p><a href='http://groups.google.com/groups?selm=20031120192528.GA6967@x-paste.de' target='_blank'>groups.google.com</a></p>
<pre>=head Do Steve Fink's debugging for him</pre>
<p>Steve Fink had a problem with some generated code throwing a segfault
when it was run and, having hit the debugging wall himself, posted the
code to the list and asked help. Leo tracked down the bug in Parrot
and fixed it. However, that's not why this made the summary, what's
interesting is the sample of code that the problem code was generated
from. Here it is:</p>
<pre>  rule thing() {
      &lt;[a-z]&gt;+
  }

  rule parens() {
      { print &quot;entering parens\n&quot;; }
      \( [ &lt;thing&gt; | &lt;parens&gt; | \s ]* \)
      { print &quot;leaving parens\n&quot;; }
  }

  sub main() {
      my $t = &quot;()()(((blah blah () blah))(blah))&quot;;
      my $t2 = $t _ &quot;)&quot;;
      print &quot;ok 8\n&quot; if $t2 !~ /^ &lt;parens&gt; $/;
  }</pre>
<p>Looks tantalizing doesn't it? Someone's now going to tell me that the
code in question has been there forever, but I'm still tantalized.</p>
<p><a href='http://groups.google.com/groups?selm=20031121071225.GI26642@foxglove' target='_blank'>groups.google.com</a></p>
<a name='Another minor tasks for the interested'></a><h2>Another minor tasks for the interested</h2>
<p>Dan discovered that a <code>make -j 4</code> dies quickly and horribly, which
seems to imply that there's a dependency or two missing from the nest
of twisty makefiles that make up the Parrot build system. He asked for
volunteers to fix things. There's been some work done on this, but no
definitive fix so far.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.58.0311211058540.29189@sprite.sidhe.org' target='_blank'>groups.google.com</a></p>
<a name='Some PIR &quot;How do I?&quot; questions'></a><h2>Some PIR &quot;How do I?&quot; questions</h2>
<p>Dan threw a list of questions about IMCC out to the list as things
that would really benefit from being documented. Sterling Hughes added
a question or two, and Melvin Smith volunteered to get the answers
written up real soon now.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.58.0311211515220.29189@sprite.sidhe.org' target='_blank'>groups.google.com</a></p>
<a name='Bytecode portability and word/int sizes'></a><h2>Bytecode portability and word/int sizes</h2>
<p>Now that Parrot has the beginnings of freeze/thaw support, Melvin
Smith restarted discussion of ensuring that Parrot's bytecode format
is portable. He pointed at several issues that need
resolving. Discussion continues.</p>
<p><a href='http://groups.google.com/groups?selm=5.1.1.6.2.20031122120034.02236230@pop.mindspring.com' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<a name='Fun with 'multi''></a><h2>Fun with 'multi'</h2>
<p>Discussion of multi dispatch rolled on into the current summary
period. Luke Palmer pointed out that <code>multi</code> is no longer a
declarator but a modifier, allowing for fine-grained control of the
'scope' of a method/function/whatever. Larry pointed out that 'multi'
is orthogonal to scope, saying simply &quot;I'm putting multiple names
into a spot that would ordinarily demand a unique name.&quot; and went on
to explain precisely what that implied.</p>
<p><a href='http://groups.google.com/groups?selm=20031110094753.GA14948@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=20031119025313.GA10300@wall.org' target='_blank'>groups.google.com</a> -- Larry Clarifies</p>
<a name='The Perl 6 design process'></a><h2>The Perl 6 design process</h2>
<p>Rod Adams worried that all of the design of Perl 6 seems to come from
Larry and Damian, with the language list being relegated to asking
questions about how stuff works in more detail and in sniffing out
tricky bits. Taken in combination with the real world's nasty habit of
saddling Larry and Damian with health and financial problems, well,
Rod worries, and wonders if there's anything that can be done to
improve matters.</p>
<p>The redoubtable chromatic (who prefers it if I always render his name
in all lower case, even at the beginning of sentences, hence his
becoming redoubtable) gave the Standard Answer to such questions,
pointing out that the reason things are going through Larry is
because, well, Larry's bloody good at it. However, he did suggest
that we're now at the point where we can probably start turning
existing design docs into story cards and programmer tests for Perl
6, which should make implementation a good deal easier, and pointed to
the Perl XP Training Wiki as a good place to look into how such tools
are used to develop code.</p>
<p><a href='http://groups.google.com/groups?selm=4.2.0.58.20031114234841.00aa39e0@rodadams.net' target='_blank'>groups.google.com</a></p>
<p><a href='http://xptrain.perl-cw.com/' target='_blank'>xptrain.perl-cw.com</a> -- The Perl XP Training Wiki</p>
<a name='Control flow variables'></a><h2>Control flow variables</h2>
<p>Luke Palmer doesn't like the repetition and ugliness inherent in code
like:</p>
<pre>  my $is_ok = 1;
  for 0..6 -&gt; $t
    { if abs(@new[$t] = @new[$t+1]) &gt; 3 { $is_ok = 0; last } }

  if $is_ok { push @moves: [$i, $j] }</pre>
<p>and wondered if there was a Perl6ish way of eliminating <code>$is_ok</code>. He
suggested something like:</p>
<pre>  for 0..6 -&gt; $t
    { if abs(@new[$t] - @new [$t+1]) &gt; 3 { last }}
  FINISH 
    { push @moves: [$i, $j] }</pre>
<p>Simon Cozens made a plea to eschew adding syntax to the language when
it would be better to find a general mechanism. He wondered if a
better approach may be to have <code>for</code> return a status, by analogy with
Perl 6's <code>if</code>, which would allow one to write:</p>
<pre>  for 0..6 -&gt; $t { 
    last if abs(@new[$t] - @new[$t+1] &gt; 3; 
  } or push @moves: [$i, $j];</pre>
<p>Which wasn't really well liked (I'm practicing my understatement here,
okay?) However, Simon's point about distinguishing between Perl 6 the
language and stuff that belongs in CP6AN (CPAN for Perl 6) was well
made and taken.</p>
<p>The thread's almost unsummarizable, it went off in so many different
directions, and elicited some good stuff from Larry about the thinking
behind Perl 6, along with a horde of solutions to Luke's problem. Some
of 'em even work in Perl 5, at the expense of some seriously ugly
looking code. Piers Cawley wrapped one solution, based on a guard
clause approach, up in a higher order function, but fumbled the ball
on working out the macro syntax, which pulled the discussion in
another direction. Meanwhile other subthreads led to discussions of
generators, coroutines, Mathematica's <code>Sow[]</code> and <code>Reap[]</code> and
legitimate uses of <code>goto</code>.</p>
<p>And Larry emphasised that nested modifiers are still quite illegal in
Standard Perl 6.</p>
<p><a href='http://groups.google.com/groups?selm=20031118142052.GA5735@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=20031119181906.GD10300@wall.org' target='_blank'>groups.google.com</a> -- Larry on language design</p>
<a name='s/// in string context should return the string'></a><h2><code>s///</code> in string context should return the string</h2>
<p>In another of those deceptively 'pregnant' posts, St&eacute;phane
Payrard proposed that <code>s///</code> in string context should return the
string after substitution. Austin Hastings proposed something scary,
which led to Larry contemplating making</p>
<pre>  $x.s/foo/bar/.s/moo/goo/;</pre>
<p>work somehow. (Which is actually less scary than Austin's original
proposal). I think he rejected the idea for the time being though.</p>
<p>Piers Cawley suggested that it should return the substituted string,
with an appropriate boolean property set depending on whether any
substitutions were made. But then there issues of how you strip such
properties off if you want to use the standard boolean interpretations
of a string. Luke Palmer suggested the rather lovely <code>but nothing</code>
meta property.</p>
<p>I have the feeling that what's actually going to happen is that we'll
end up with a supplementary, non destructive form of <code>s///</code> which
doesn't alter the original string, but returns a new string with the
substitutions made.</p>
<p><a href='http://groups.google.com/groups?selm=20031118171859.GH3887@stefp.dyndns.org' target='_blank'>groups.google.com</a></p>
<a name='Acknowledgements, Apologies, Announcements'></a><h1>Acknowledgements, Apologies, Announcements</h1>
<p>Sorry, we're a tad late again, sorry too to those of you reading this
on the mailing lists, I've not got 'round to reimplementing the
software to shorten the article URLs.</p>
<p>If you find these summaries useful or enjoyable you might  like to
show your appreciation by contributing money or time to the Perl
Foundation and the Perl 6  effort. , or you could give me feedback
directly at <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i>, or stop by at my website.</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> -- Perl 6 Development site</p>
<p><a href='http://www.bofh.org.uk:8080/' target='_blank'>www.bofh.org.uk</a> -- My website, &quot;Just a Summary&quot;</p>
</div>
